Celestin Apprentice 2/Apprentice-Release2.iso/Tools/Languages/Harvest C 1.3/README

Text File | 1993-06-20 | 11.1 KB | 279 lines | [TEXT/R*ch]

Release Notes
Harvest C 1.3
21 June 1993
Copyright 1993 Eric W. Sink

This release of Harvest C fixes a few bugs and such from 1.2, released about
a year ago.  I have done virtually no work on the project in the last year, and
I have no plans of putting significant time into it in the foreseeable future.  The
full source code to the compiler continues to be available under the terms of
the GNU Public License.

These notes are not intended to be a user's manual.  In fact, no formal documentation
is included with this release at all.

Harvest C *should* work on any Mac with System 6 or 7, minimum 4 meg
RAM.  It is 32-bit clean and virtual memory compatible.  It is System
7-Friendly in that it supports AppleEvents, but it does not support
Balloon Help.  Don't even try using it without 4 meg of RAM.  It will
be deathly slow on a 68000 machine, if it works at all.

Areas of the great unknown:

1.  I have no idea if this will still work on a 68000 machine, since
        I don't have one to test it on.  It should.

2.  Same goes for System 6.

3.  Floating point is rather untested.  68881 code has not been tested
        since the last day it ran on the Sun (it worked great then).  I
        would be very surprised if it worked now.

4.  68020 code generation has not been tested since it ran on the Sun.

5.  I've never built a Harvest C project with more than about 6 files.
        I'd like to know how it performs on a project with say, 25 C source
        files.

6.  Support for big globals (> 32k) exists, but has never been tested.
        Ever.

Comments:

Give Harvest C lots of memory.  The minimum MF partition is
2000k.

Harvest C is still not very efficient with memory, and I'm certain
there are still leaks.

NOTE
The C source files must be in the same folder as their project file.
NOTE

The MPW 3.2 headers must be in a folder called "(Harvest C Headers)",
in the same folder as the Harvest C application.  The MPW 3.2 libs
must be in a folder called "(Harvest C Libraries)", also in the same
folder as the Harvest C application.  To test this, open Harvest C,
and create a new project.  The project will have two libraries in it
(Interface.o and Runtime.o) if and only if your libraries are in the
right place.  When naming those folders, include the parens, but not
the quotes.

Harvest C will interact with Alpha and ResEdit using AppleEvents, if
you launch them.  From the project window, double click on a C source
file, and it will open in Alpha.  Double click on a resource file, and
it will open in ResEdit.

Currently, all option settings apply to every file in the project.  Version
1.2 no longer allows separate option settings for each file.  For now, take
note that a change in option settings does NOT mark every file as needing
recompilation.

Several sample programs are included with this release.

Harvest C currently does not support compiling anything except
applications (ie no CODE resources, XCMDs, DAs, etc)

Harvest C 1.3 no longer has a Tool Command Language shell.

There are some menu items which are ALWAYS grey, because Harvest C
doesn't really have that feature yet.

----------Interfaces & Libraries

In order for your program to be linked to form an application, you
must link with some standard libraries.  These libraries allow access
to Toolbox routines, handle initialization of global variables, and
things like that.  Furthermore, use of these libraries will generally
require that you use the interface (or header) files which accompany
them.

You must obtain Apple's headers and libraries in order to use Harvest
C.  I do not have legal permission to distribute them.  They are
sold from the Apple Programmers and Developers Association, and are
called "MPW Toolbox Interfaces and Libraries v. 7.0", product number
M0615LL/B, at a cost of $40.  You may reach APDA at :
        APDA
        Apple Computer, Inc.
        20525 Mariani Avenue
        Mail Stop 33G
        Cupertino, CA 95014-6299

You may also obtain the necessary headers and libraries by anonymous
ftp from ftp.apple.com.  I do not know which directory they are currently
in, so dig around a little.

Harvest C will NOT work with the MPW 3.1 headers and libraries.

CURRENT PROBLEMS (not really edited since 1.2)

As no software is bug free, and compilers are particularly prone to
problems, I will not be so foolish as to claim that Harvest C is
perfect.  The following items are already known :

-----General deficiencies
        The compiler is slow.

        Harvest C does not support the MPW comp data type

        The Harvest C Linker is not as smart as the MPW linker.  It
produces somewhat bloated applications.

        Harvest C is a memory hog.

        Harvest C sometimes produces code which is truly inane.

-----Bugs
        The reliability of floating point math is not fully known.

        There are memory leaks.

--- NOTICE ---

    Harvest C is free software; you can redistribute it and/or modify
    it under the terms of the GNU Generic Public License as published by
    the Free Software Foundation; either version 2, or (at your option)
    any later version.

    Harvest C is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with Harvest C; see the file COPYING.  If not, write to
    the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.

    Harvest C is not in any way a product of the Free Software Foundation.
    Harvest C is not GNU software.
    Harvest C is not public domain.
    Harvest C is not shareware.

    Various parts of Harvest C were not necessarily written by me (Eric Sink).
    These parts are not necessarily covered by the GNU General Public License,
    as I do not hold the copyright on those parts of the code.

    The user interface for Harvest C was written using the THINK Class
    Library.  As the THINK C manual recommends creating applications by
    copying and modifying their example applications, I have done just that.
    Their copyright remains intact in each file where this is the case.


--- End of NOTICE ---

Please note that Harvest C will NOT compile itself.  If you intend to
compile Harvest C using the source code obtained from me, you must use
THINK C 5.0.  The Harvest C source code makes use of the object oriented
extensions to THINK C which are not included in Harvest C itself.  The
program MIGHT compile under THINK C 6.0, but I've never tried it.

The intent of making the source code available is to make Harvest C a
bit more detached from me.  For Harvest C to survive beyond my limited
constraints, it needs to be in the hands of more than one developer.  Many
have offered to help with the compiler, and I want to give you the
chance to do so.

Harvest C uses the malloc package written by Tim Endres.  The user interface
was done with the THINK Class Library.  The assembler module was
adapted from a public domain 68k assembler, though extensive
modifications have been made.

Notes on the Harvest C source code

You must have THINK C 5.0x to compile Harvest C.

The project file contains all the Harvest C source files, plus lots
of TCL files (which you already have), plus several customized libraries.
These libraries are named things like "ANSI 4 byte".  Create these by
copying the appropriate THINK C library, modifying the option settings
to be exactly like those in the Harvest C project, and recompile.

I didn't write all of the code included here.  The assembler
routines were obtained from the Motorola BBS.  The malloc library was
written by Tim Endres.

You may note that much of the code is hard to read, or not very well written.
You're right.  I wrote Harvest C as a learning experience.  I constantly
learned from my own mistakes.  Some of those mistakes have already been
corrected through rewrites.  Some have not.  Almost invariably, I am
very aware of the deficiencies in this program and its design.  The limiting
factor which keeps me from fixing things is time, not [entirely] knowledge.
The bottom line here is: I am making myself vulnerable by releasing code
which I know is in many ways far from perfect.  I will answer questions.  I
would prefer not to receive gripes or complaints.

If you know a lot about compilers, it would probably not be a good idea
to read the code in the parser, lexer, etc...  I know better now.

If you are just learning about compilers, read a compiler text.  Your best
learning experience w.r.t. Harvest C will be the ability to identify my
mistakes.  I knew very little when I wrote some of this -- I would do much of it
differently now.

Harvest C is badly hurting in terms of source file organization.  Too many
things get included in every file, and the layout of functions among files
does not always make much sense.

Harvest C was originally written on a Sun 3, using malloc() for dynamic memory
allocation.  I later ported to the Mac, and used NewHandle().  Anticipating
this change, most struct references look like this

    Via(s)->member;

instead of

    s->member;

where Via() is a preprocessor macro which determines whether or not we are
using malloc().  Current memory allocation uses malloc(), so Via expands
to have no effect.

You may be thinking about continuing to improve Harvest C and make it
the greatest free C compiler around.  I'd advise that you channel that
enthusiasm into the efforts at porting GCC 2 to the Mac, based partially
on Harvest C's code.  Remember this:

I know Harvest C better than anyone (I wrote it).  I estimate that the
effort necessary for ME to make Harvest C a robust, awesome compiler would be
FAR greater than the effort necessary to port GCC 2 and integrate the Harvest C
linker and some other things.  If you really want to see a great free C
compiler for the Macintosh, direct your efforts toward GCC.  Stan Shebs is
involved in work along these lines, as well as others.

In any case, the source code is here, for your pleasure.

Acknowledgements

I never know who to thank.  Requiring me to judge the relative merits
of others' contributions to this project seems a bit much.  The
following people come to mind right now.  If your name belongs here,
let me know, and I'm sorry I omitted you.

Pete Keleher, for feedback and helping integrate Harvest C with Alpha.
Jon W{tte, for extensive feedback (more messages in my Harvest C mail folder
        than anyone except Pete!)
Michael Dautermann, for being very patient, and because he deserves
        all the credit he can get.
Terry Thiel, for writing the ACM (:-) article
Jersey Scientific, for contributing dev tools
Paul Madden, for writing the DI article
Tim Endres, for the malloc source

My address appears below.  The volume of mail I get regarding Harvest C far
exceeds the time committment I want to make, so I don't always answer right away.
A few pieces of mail have gone totally answered, sorry.  If you contact me, please
remember that I'm not actively working on this project at all.

Eric W. Sink
1014 Pomona Drive
Champaign, IL  61821
[e-mail]

Sometime around the fall of 1993, my addresses should probably change to:

Eric W. Sink
3101 Amy Drive
Champaign, IL  61821
[e-mail]